System Center Configuration Manager и как с ним бороться

Столкнулись с ситуацией, когда клиенты массово не могут зарегистрироваться на точке управления, что видно из апплета в Панели управления, который не показывает информацию о самоподписанном сертификате.

CcmMessaging.log:

Successfully queued event on HTTP/HTTPS failure for server ‘FR-Server.grp’.

Post to http://FR-Server.grp/ccm_system_windowsauth/request failed with 0x87d00231.

[CCMHTTP] ERROR: URL=http://FR-Server.grp/ccm_system_windowsauth/request, Port=80, Options=224, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE

Raising event:Raising event:instance of CCM_CcmHttp_Status{ DateTime = «20170421111806.430000+000»; HostName = «FR-Server.grp»; HRESULT = «0x87d0027e»; ProcessID = 4064; StatusCode = 403; ThreadID = 884;};

ClientIDManagerStartup.log:

[RegTask] — Client is not registered. Sending registration request for GUID:DE58A634-DCC5-443A-A3CF-78B8699B5EDF …

RegTask: Failed to send registration request message. Error: 0x87d00231

RegTask: Failed to send registration request. Error: 0x87d00231

LocationServices.log:

1 assigned MP errors in the last 10 minutes, threshold is 5.

2 assigned MP errors in the last 10 minutes, threshold is 5.

3 assigned MP errors in the last 10 minutes, threshold is 5.

4 assigned MP errors in the last 10 minutes, threshold is 5.

Assigned MP error threshold reached, moving to next MP.

И никакой подробной информации в ClientLocation.log:

Current AD forest name is MEGAdomain.grp, domain name is MEGAdomain.grp

Domain joined client is in Intranet

Current assigned management point is the only assigned management point.

Источник проблемы нашёлся в логах IIS, который отбрасывал запросы клиентов с кодом 403:

10.160.52.36 GET /SMS_MP/.sms_aut MPLIST1&CM1 80 — 10.160.18.104 SMS+CCM+5.0 — 200 0 0 433 42

10.160.52.36 CCM_POST /ccm_system_windowsauth/request — 80 — 10.160.48.72 ccmhttp — 403 18 0 1393 50

10.160.52.36 CCM_POST /ccm_system/request — 80 — 10.160.68.234 ccmhttp — 200 0 0 8583 118

10.160.52.36 CCM_POST /ccm_system_windowsauth/request — 80 — 10.160.68.234 ccmhttp — 403 18 0 1393 39

10.160.52.36 POST /SMS_FSP/.sms_fsp — 80 — 10.160.68.234 ccmhttp — 200 0 0 149 36

10.160.52.36 POST /SMS_FSP/.sms_fsp — 80 — 10.160.68.234 ccmhttp — 200 0 0 149 36

10.160.52.36 CCM_POST /ccm_system_windowsauth/request — 80 — 10.160.4.244 ccmhttp — 403 18 0 1393 52

10.160.52.36 CCM_POST /ccm_system_windowsauth/request — 80 — 10.160.159.46 ccmhttp — 403 18 0 1393 85

Что и подтвердилось попыткой зайти напрямую на IIS:

Поскольку в продуктивной среде у нас была только одна точка управления, я решил её не трогать и установить на временный сервер вторую точку, которая сразу же начала корректно принимать запросы:

10.160.52.202 CCM_POST /ccm_system/request — 80 — 10.160.154.4 ccmhttp — 200 0 0 124

10.160.52.202 CCM_POST /ccm_system/request — 80 — 10.160.154.4 ccmhttp — 200 0 0 125

10.160.52.202 CCM_POST /ccm_system/request — 80 — 10.160.154.4 ccmhttp — 200 0 0 125

10.160.52.202 CCM_POST /ccm_system_windowsauth/request — 80 — 10.160.52.154 ccmhttp — 401 2 5 0

10.160.52.202 CCM_POST /ccm_system/request — 80 — 10.160.154.4 ccmhttp — 200 0 0 141

10.160.52.202 CCM_POST /ccm_system_windowsauth/request — 80 MEGAdomain\pc-ext 10.160.52.154 ccmhttp — 200 0 0 46

10.160.52.202 GET /SMS_MP/.sms_aut MPLIST 80 — 10.160.154.4 SMS+CCM+5.0 — 200 0 0 31